GKEで遊ぶ時の手順
概要
メモまでに、GKEで遊ぶ/遊んだ時のいろいろを書いておく。
SDK入れる
gcloud何ちゃら入れる
クラスタ用意する
https://console.cloud.google.com/kubernetes/
から頑張る
ContainerRegistryにアップするDocker imageを作る
ふつーにbuildで作成する。
作成したimageをContainerRegistryにアップする
タグつけてgcloudコマンドでアップ。タグつけるときにtagをつけなければ自動的にlatestがつく。
docker tag image_name asia.gcr.io/project_name/image_name:tag
gcloud docker -- push asia.gcr.io/project_name/image_name
ContainerRegistryにアップしたコンテナをGKEで使う
さきほどpushしたものがgcloudから検知できるかチェック
gcloud container images list-tags asia.gcr.io/project_name/image_name
で、なんかヒットするはず。
Deploymentを作成してGKEへとデプロイ
手元のマシンのkubectlの設定を変え、接続対象をGKEの特定のクラスタへと変更する。
まずはkubectlの現在のコンテキスト(接続先)を確認。
kubectl config current-context
で、接続先がGKEの意図したクラスタでない場合、gcloudコマンドを使ってそのパラメータを変更する。
gcloud container clusters get-credentials your_cluster_name --zone your_zone
この状態でもう一度current-contextをみると、変わっているはず。
gke_your_project_name_asia-east1-a_your_cluster_name
つまりクラスタ毎にデプロイしたい場合はこれらのコマンドを使っていちいちクラスタ切り替えないと行けないわけだね。
手元からやるもんじゃねーな。
role.json
{
"apiVersion": "extensions/v1beta1",
"kind": "Deployment",
"metadata": {
"name": "role-deployment",
"labels": {
"app": "role"
}
},
"spec": {
"replicas": 1,
"selector": {
"matchLabels": {
"app": "role"
}
},
"template": {
"metadata": {
"labels": {
"app": "role"
}
},
"spec": {
"containers": [
{
"name": "role",
"image": "asia.gcr.io/dev-milive/dev-role",
"ports": [
{
"containerPort": your_port2
},
{
"containerPort": your_port
}
]
}
]
}
}
}
}
で、kubectl apply コマンドでデプロイできる。
kubectl apply -f role.json
この時点でGKEのページからデプロイ済みの確認が取れた。ノードの詳細画面の一番下にデプロイされてるのを確認。
role.jsonには次のようなパラメータをセットしてたんだけど、
{
"apiVersion": "extensions/v1beta1",
"kind": "Deployment",
これ、なんでextensions/v1beta1 とかになるんだろう。minikubeでやってたみたいにapps/v1ではいけないんだろうか？
-> ここの設定に則ってるっぽい。 k8s公式。
https://kubernetes.io/docs/reference/generated/federation/extensions/v1beta1/definitions/
デプロイ済みの要素にアクセスする
次に、外部からアクセスできるようにserviceを設定する。このへんもjson書いてやる。
kubectl create -f svc_role.json
複数のポートの指定もできてると思うんだけど、アクセスができない。なんでだろ。
https以外でのアクセスができない + コンテナがそれに対応してない的な？
-> 違った。
kubectl expose deployment -l app=role -p your_port --type "LoadBalancer"
とかダイレクトにやったら接続できた。やったぜ！
ということはファイルで書いたServiceの記述がまちがっている。
差
x role LoadBalancer 10.35.248.38 104.199.151.125 your_port2:30247/TCP,your_port:30368/TCP 12h
o role-deployment LoadBalancer 10.35.250.167 35.229.178.174 your_port:31518/TCP 2m
なるほど、exposeしてる対象が異なるのか。さらになんか違いそう。
kubectl expose deployment role-deployment --port=your_port,your_port2 --type="LoadBalancer"
とかだと複数portいけた。やったぜ。で、
じゃあこれはどんなデータになってるんだろう、、、jsonにできないとつらいぞ、、
-> get svc 名前 -o yamlで取り出して云々して比較した。jsonでも取り出せる？ -> 出せた。
kubectl get svc role-deployment -o json
ということで、一度コマンドラインで作ってからうまくいったらjsonにして云々みたいなテクを覚えた。
いい感じに動くようになった～～わーい。
最終的なサービスを作成するためのjsonはこれ
svc_role.json
{
"apiVersion": "v1",
"kind": "Service",
"metadata": {
"labels": {
"app": "role"
},
"name": "role-deployment"
},
"spec": {
"ports": [
{
"name": "p1",
"port": your_port
},
{
"name": "p2",
"port": your_port2
}
],
"selector": {
"app": "role"
},
"type": "LoadBalancer"
}
}
教訓:
・deploymentにつける名前とserviceにつける名前で一致してないと行けない部分がある。
・selectorについてもっと学ぶ必要がある。どんな指向性してるんだかをもっと把握しないとな＝～。
ContainerBuilderを使ってコードからDockerImageをビルド(おまけ)
ビルドリクエストを出してDocker imageを生成する。
githubとかから引っ張り出して実行できる模様。
このへんのパイプラインを構築しないとな。
少なくともcontainerRegistryへのアップとかは手元からやるルートと自動化ルートの両方が欲しい。